home *** CD-ROM | disk | FTP | other *** search
/ Software of the Month Club 2000 October / Software of the Month - Ultimate Collection Shareware 277.iso / pc / PROGRAMS / UTILITY / WINLINUX / DATA1.CAB / programs_-_usrdoc / PROCMAIL.{23 / INSTALL.{_3 < prev    next >
Text File  |  1999-09-17  |  9KB  |  196 lines
  1. Discusses:
  2.         1. Getting the lot to compile
  3.         2. IMPORTANT info for people with remote filesystems (like NFS)
  4.         3. DEBUGGING AID
  5.         4. Setting up the environment
  6.         5. Extra options if you are a system administrator
  7.  
  8.                 ---
  9.  
  10. 1. Getting the lot to compile
  11.    --------------------------
  12.  
  13. To install procmail, lockfile and formail: edit Makefile & config.h accordingly
  14. and type 'make install'.
  15. Intended configurable options in Makefile are:
  16.     the install-destinations and the LOCKINGTEST directories (you can
  17.     optionally use something like 'make BASENAME=$HOME install' instead).
  18. Intended configurable options in config.h are:
  19.     MMDF support, standard environment presettings including PATH,
  20.     trusted userids.
  21.  
  22. 'make install' will:
  23.       - implicitly do a 'make init', which will check your basic utilities for
  24.     POSIX compliance, and generates correcting Makefiles accordingly
  25.       - execute autoconf (a shell script that repeatedly calls the C compiler
  26.     to determine if certain features/symbols are supported), which will
  27.     create a file named autoconf.h
  28.       - create three stripped binaries, a shell script and five man pages in
  29.     the new/ subdirectory (all that is needed to install):
  30.     procmail, lockfile, formail, mailstat, procmail.1, lockfile.1,
  31.     formail.1, procmailrc.5, procmailsc.5, procmailex.5
  32.       - copy these binaries and mailstat to $(BINDIR)
  33.       - copy the man pages to $(MAN1DIR) and $(MAN5DIR)
  34.       - BEWARE: the installation obeys the current umask setting.  If you
  35.     want the files to be available to anyone, correct your umask first.
  36.  
  37. 'make deinstall' will:
  38.       - remove the just installed files in $(BINDIR)
  39.       - remove the just installed files in $(MAN1DIR) and $(MAN5DIR)
  40.  
  41.  
  42. Minimal requirements (for regular uses):
  43.  
  44. procmail must be installed.
  45.  
  46. Optional files (depending on your requirements):
  47.  
  48. lockfile only needs to be installed if you plan to read several mailboxes
  49.     with one of the standard mailers that doesn't support lockfiles.
  50. formail only needs to be installed if mail sometimes arrives in nonstandard
  51.     mailbox format (or if you want to generate auto replies, split up
  52.     mailboxes/digests etc., see the man page of formail for more info).
  53. mailstat is an "example" shell script that can be used as is to produce
  54.     summaries of the procmail generated logfiles; it is not needed by
  55.     procmail itself in any way.
  56.  
  57. procmail, lockfile, formail and mailstat are all *standalone* programs, i.e.
  58. they do *not* use any compiled-in paths or files that need to be there, they
  59. all can be used and installed independently without the need to install the
  60. others.
  61.  
  62. If things don't compile automagically, I suggest you take a look at:
  63. src/autoconf, autoconf.h, config.h, src/includes.h
  64.  
  65. For autoconf to work as intended, your compiler should either be fully ANSI
  66. compliant, or you should NOT turn off all warnings; enabling all warnings
  67. shouldn't hurt.     In most cases the default options in the Makefile will do.
  68.  
  69. The sources are supposed to be fully ANSI, K&R and POSIX compliant.
  70.  
  71. N.B. If you encounter any difficulty at all in installing procmail (e.g. if you
  72.      had to change Makefile or config.h in unpredicted ways, or a simple
  73.      "make install" doesn't work), I'd very much like to hear about it; who
  74.      knows, next time you might be able to simply "make install" as well.
  75.  
  76.                 ---
  77.  
  78. 2. IMPORTANT info for people with remote filesystems (like NFS)
  79.    ------------------------------------------------------------
  80.  
  81. The autoconf script tries to determine what kernel locking functions are
  82. available *and* reliable on your system.  In order to do this it exercises
  83. all the available locking methods (fcntl(), lockf() and flock()) on some
  84. sample files extensively.
  85.  
  86. These tests produce results which depend on the filesystem which is being
  87. used to perform the tests.  If you haven't defined LOCKINGTEST in the Makefile
  88. (you can include as many directories as you want) autoconf will prompt you
  89. to enter any additional directories (preferably on distinct filesystems)
  90. you want it to run the tests on.
  91.  
  92. When specifying directories to test, it would probably be advisable to
  93. pick exactly those directories which belong to a unique fileserver-fileclient
  94. pair.  I.e. one local file system will suffice.     Only if you have remote
  95. filesystems, you might have to specify several.
  96. This makes sure that the locking tests will properly reflect the (lowest common
  97. denominator) locking capabilities on all filesystems available.
  98.  
  99. If you have a very heterogenous environment (like several OS versions
  100. on machines (perhaps even from different vendors) that have NFS mounted file
  101. systems all over each other), then it could happen that some tests which
  102. are reliable with one remote filesystem, turn out to be unreliable across
  103. another (it all depends on the OS versions of clients and servers).
  104.  
  105. If do not want to perform the locking tests on all those filesystems, but
  106. if you know what locking methods are unreliable anyway, then you can edit
  107. some defines in the config.h file (NO_fcntl_LOCK, NO_lockf_LOCK and
  108. NO_flock_LOCK).     These can be uncommented by hand to prevent procmail
  109. from using them.
  110.  
  111. The most typical case would be if you happen to be using NFS.  Autoconf
  112. normally is very well capable of finding out if your lockd is reliable enough.
  113. In a very heterogenous environment (many different servers, many different
  114. lockd's (of perhaps different version and patchlevel)) however, it might
  115. be hard to determine if all the lockd's are equally reliable.  In such a
  116. case (typically on SunOS :-), you might consider uncommenting both
  117. NO_fcntl_LOCK and NO_lockf_LOCK (NO_flock_LOCK normally doesn't rely on the
  118. infamous lockd, so you can leave it commented out).  But, only do so if you
  119. think you know it better than autoconf.
  120.  
  121.                 ---
  122.  
  123. 3. DEBUGGING AID
  124.    -------------
  125.  
  126. Since procmail is intended to run completely independent of any terminals, you
  127. will typically have difficulties seeing it display error messages on the stderr
  128. output.     It is recommended, especially during debugging, to specify a LOGFILE
  129. (see the procmailrc(5) man page) in the rcfile or on the command line.
  130. Procmail will log all serious problems it encounters.  Of course, instead of a
  131. regular file, one could also specify a terminal as the default logfile.
  132.  
  133. Also, procmail can be persuaded to be a lot more verbose by inserting the
  134. following assignment at the top of your rcfile:
  135.  
  136.     VERBOSE=on
  137.  
  138. Therefore a suggested command line for your first trial run (no rcfiles
  139. needed) would be:
  140.  
  141.     procmail VERBOSE=on
  142.  
  143. (now type in a pseudo mail-message)
  144.  
  145. If all else fails, you can try uncommenting the "#define console" entry
  146. in the config.h file.  This will provide you with the most verbose procmail
  147. you can make.  It is of course a good idea to comment out this line again
  148. after your troubles have been solved.
  149.  
  150. If you run procmail by hand and pipe in some sample mail, then make
  151. sure that if you kill procmail, you use "kill pid" and NOT "kill -9 pid".
  152. Should procmail seem to hang, check if any lockfiles are still present.
  153. If you kill procmail with "kill pid" it will clean up any lockfiles it created
  154. itself.
  155.  
  156.                 ---
  157.  
  158. 4. Setting up the environment
  159.    --------------------------
  160.  
  161. Every user that wants to use procmail should have a .forward and a
  162. .procmailrc file in his HOME directory.     For starters, you can look
  163. at the supplied example files in "examples" or the NOTES section in
  164. the procmail(1) man page.
  165. BTW, be sure to make .forward *world* readable.
  166. MMDF users should note that they need a .maildelivery file *instead* of the
  167. .forward file (see the procmail(1) man page for more information).
  168.  
  169.                 ---
  170.  
  171. 5. Extra options if you are a system administrator
  172.    -----------------------------------------------
  173.  
  174. If you are a system administrator you can decide to install procmail
  175. globally (i.e. as a more robust drop-in replacement for the local-
  176. maildelivery-capabilities of /bin/mail, this also gets rid of the known
  177. security holes in some /bin/mails), this has the advantage that users do
  178. not need to have a .forward file anymore that calls up procmail.  Simply
  179. having a .procmailrc file in the HOME directory will suffice.  Operation is
  180. transparent in this case (i.e. if no .procmailrc file is present in the HOME
  181. directory, mail will be delivered as usual and procmail behaves like a faster
  182. and more reliable /bin/mail substitute).
  183.  
  184. For direct examples on how to do this, look at the examples/advanced file.
  185.  
  186. *******************************************************************************
  187. HIGHLY RECOMMENDED: install "procmail" suid root (and/or sgid maildaemon)
  188.             install "lockfile" sgid maildaemon
  189.  
  190. To obtain specific instructions on the best installation, type "make recommend"
  191. *******************************************************************************
  192.  
  193.                 ---
  194.  
  195. For more info about the program, see the man pages or the FAQ list.
  196.